NonVolatile Memory With Block Management

ABSTRACT

In a nonvolatile memory system that includes a block-erasable memory array, records are individually maintained for certain classifications of blocks. One or more lists may be maintained for the blocks, an individual list ordered according to a descriptor value. Such ordered lists allow rapid identification of a block by descriptor value.

CROSS-REFERENCE TO RELATED APPLICATIONS

The benefit is claimed of U.S. provisional patent applications of AlanW. Sinclair and Barry Wright, Application No. 60/705,388, filed Aug. 3,2005 and Application No. 60/746,740, filed May 8, 2006.

This application is also related to U.S. patent application Ser. No.______, [Docket 499US1], entitled “Indexing of File Data inReprogrammable Non-Volatile Memories That Directly Store Data Files” andApplication No. ______ [Docket 499US2], entitled “ReprogrammableNon-Volatile Memory Systems with Indexing of Directly Stored Data Files”and Application No. ______ [Docket 506US1], entitled “Methods ofManaging Blocks in Nonvolatile Memory”, all naming as inventors Alan W.Sinclair and Barry Wright and all filed concurrently herewith.

This application is also related to U.S. patent application Ser. Nos.11/060,174, 11/060,248 and 11/060,249, all filed on Feb. 16, 2005,naming as inventors either Alan W. Sinclair alone or with Peter J.Smith.

This application is also related to the following four U.S. utilitypatent applications of Alan W. Sinclair and Barry Wright: applicationSer. No. 11/382,224, entitled “Management of Memory Blocks That DirectlyStore Data Files;” application Ser. No. 11/382,228, entitled “MemorySystem With Management of Memory Blocks That Directly Store Data Files;”application Ser. No. 11/382,232, entitled “Reclaiming Data StorageCapacity in Flash Memories;” application Ser. No. 11/382,235, entitled“Reclaiming Data Storage Capacity in Flash Memory Systems,” and aprovisional application by them, Application No. 60/746,742, entitled“File Data Indexing in Flash Memory,” all filed on May 8, 2006.

Any and all patents, patent applications, articles, and otherpublications and documents referenced herein are hereby incorporatedherein by those references in their entirety for all purposes. To theextent of any inconsistency or conflict in the definition or use ofterms between the present application and any incorporated patents,patent applications, articles or other publications and documents, thoseof the present application shall prevail.

BACKGROUND AND SUMMARY

This application relates to the operation of re-programmablenon-volatile memory systems such as semiconductor flash memory, and,more specifically, to the management of individually erasable blocks ofa memory array.

There are two primary techniques by which data communicated throughexternal interfaces of host systems, memory systems and other electronicsystems are addressed. In one of them, addresses of data files generatedor received by the system are mapped into distinct ranges of acontinuous logical address space established for the system in terms oflogical blocks of data (hereinafter the “LBA interface”). The extent ofthe address space is typically sufficient to cover the full range ofaddresses that the system is capable of handling. In one example,magnetic disk storage drives communicate with computers or other hostsystems through such a logical address space. This address space has anextent sufficient to address the entire data storage capacity of thedisk drive.

Flash memory systems are most commonly provided in the form of a memorycard or flash drive that is removably connected with a variety of hostssuch as a personal computer, a camera or the like, but may also beembedded within such host systems. When writing data to the memory, thehost typically assigns unique logical addresses to sectors, clusters orother units of data within a continuous virtual address space of thememory system. Like a disk operating system (DOS), the host writes datato, and reads data from, addresses within the logical address space ofthe memory system. A controller within the memory system translateslogical addresses received from the host into physical addresses withinthe memory array, where the data are actually stored, and then keepstrack of these address translations. The data storage capacity of thememory system is at least as large as the amount of data that isaddressable over the entire logical address space defined for the memorysystem.

In current commercial flash memory systems, the size of the erase unithas been increased to a block of enough memory cells to store multiplesectors of data. Indeed, many pages of data are stored in one block, anda page may store multiple sectors of data. Further, two or more blocksare often operated together as metablocks, and the pages of such blockslogically linked together as metapages. A page or metapage of data arewritten and read together, which can include many sectors of data, thusincreasing the parallelism of the operation. Along with such largecapacity operating units come challenges in operating them efficiently.

For ease of explanation, unless otherwise specified, it is intended thatthe term “block” as used herein refer to either the block unit of eraseor a multiple block “metablock,” depending upon whether metablocks arebeing used in a specific system. Similarly, reference to a “page” hereinmay refer to a unit of programming within a single block or a “metapage”within a metablock, depending upon the system configuration.

When the currently prevalent LBA interface to the memory system is used,files generated by a host to which the memory is connected are assignedunique addresses within the logical address space of the interface. Thememory system then commonly maps data between the logical address spaceand pages of the physical blocks of memory. The memory system keepstrack of how the logical address space is mapped into the physicalmemory but the host is unaware of this. The host keeps track of theaddresses of its data files within the logical address space but thememory system operates with little or no knowledge of this mapping.

In the second of the two system interface techniques that are used, datafiles generated or received by an electronic system are uniquelyidentified and their data logically addressed by offsets within thefile. A form of this addressing method is used between computers orother host systems and a removable memory card known as a “Smart Card.”Smart Cards are typically used by consumers for identification, banking,point-of-sale purchases, ATM access and the like, and contain a smallamount of memory when compared to flash memory cards and flash drives.

In the patent applications cross-referenced above, a data file isidentified in the mass storage flash memory system by a filenameassigned by the host and data of the file are accessed by offsetaddresses within the file (hereinafter “direct data file interface”).The memory system then knows the host file to which each sector or otherunit of data belongs. The file unit being discussed herein is a set ofdata that is ordered, such as by having sequential logical offsetaddresses, and which is created and uniquely identified by anapplication program operating in a host computing system to which thememory system is connected.

The four utility patent applications referenced above (application Ser.Nos. 11/382,224; 11/382,228; 11/382,232; 11/382,235), filed on May 8,2006), describe techniques in which lists of blocks are maintained foraccess during operation of the memory system. Individual entries on thelists include parameters of memory blocks and their addresses. An entrywithin a list may be selected according to either the physical addressof the block to which it relates, or the value of a block parameter thatis recorded within the entry. The present description relates to storingone or more lists of data blocks within a designated block in flashmemory, and accessing a specific entry in a list on the basis of theinformation content of a field within the entry.

The technique uses some of the logical pages in the designated block forstorage of unordered records containing information of all blocks on twoor more lists. Other pages are used for lists of entries containing onlya content-addressable parameter for the blocks, and a pointer to thefull record for the block. Entries in these lists are stored in order ofthe parameter values, and an entry with a specific parameter value canquickly be accessed. The lists act as a form of directory to theunordered records for the blocks.

In a block-erasable nonvolatile memory, maintaining up-to-dateinformation on individual blocks and the data they contain allowsefficient memory management. Where blocks contain a mixture of validdata of one or more files, obsolete data, and erased space this may bequite complex. However, by keeping track of such data on ablock-by-block basis, certain memory system operations, particularlyreclaiming of unused space in the memory array, may be efficientlyperformed. Reclaim of unused space (space containing obsolete data orunusable erased space) takes place on a block-by-block basis (where ablock is the unit of erase). It is desirable to perform block reclaimoperations on blocks in an efficient order, to reduce copying of validdata. To determine the order of block reclaim, it is useful to haveblocks ranked in order of one or more descriptor values, where adescriptor value is descriptive of at least one aspect of the datastored in a block. For example, blocks may be ordered by the amount ofvalid data they contain so that those blocks containing the least amountof valid data may be quickly identified to be reclaimed first.

In a first example, records are maintained for a variety of blocks inthe memory array, though not necessarily all blocks. Blocks containingvalid data are classified according to whether they contain erased space(partial blocks) and if not, whether they contain obsolete data(obsolete blocks). Blocks with only obsolete data (invalid blocks) andblocks containing only erased space (erased blocks) are separatelyclassified. A record is maintained for each block having one of theseclassifications. Records are maintained in dedicated record blocks. Inaddition, blocks in a classification are listed in lists that areordered by a descriptor value. The descriptor value may be the amount ofvalid data in the block, the address of the block or some otherdescriptor value. List entries, in the first example, contain pointersto corresponding records.

In a second example, records are also maintained for blocks in variousclassifications. The classification “complete common block” is added fora block that contains data of more than one file and that does notcontain obsolete data or erased space. Records are maintained indedicated record pages in dedicated record blocks. A record may containa variety of information regarding the corresponding block including itsblock address, the amount of valid data it contains, position of writepointer etc.

A directory is provided to allow an individual record to be rapidlyfound. An entry in the directory identifies a record page and thelocation of the corresponding record in that record page. The directoryis maintained in dedicated directory pages in a directory block, withdirectory entries ordered by block address. Directory pages containnon-overlapping block address ranges. One directory page may containpointers to more than one record page. However, a record page containsonly records pointed to by entries of one directory page. Thus, whenrecords in a record page are updated, only one directory page needs tobe updated.

Directory blocks may also contain one or more lists. An entry in a listcontains a block address and a descriptor value and entries in a listare ordered by descriptor value. An exemplary descriptor value is theamount of valid data in a block. Lists provide a convenient way toselect a block for reclaim or other purposes based on data in the block.For example, the obsolete block with the least amount of valid data isthe first entry in a list of obsolete blocks that uses the amount ofvalid data as descriptor value. This block can be rapidly identifiedfrom the list for reclaim so that the list provides a queue for reclaimoperations. In other examples, a block with a particular descriptorvalue may be sought. This may be identified rapidly by performing abinary search on the appropriate list page.

In a third example, a record is maintained for each block in thenonvolatile memory array at all times. In this case, a directory pagecontains entries for a fixed block address range with entriessequentially ordered by block address. Because this provides an entryfor a particular block at a predetermined offset within a directorypage, entries do not have to contain the block address of the block towhich they refer.

Although the techniques of managing and accessing lists are describedherein for use with flash memory operating with a flash data fileinterface, these techniques may also be used with other types of listsin different applications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a table of block classifications according to a firstexample.

FIG. 2 shows pages of a record block according to the first example.

FIG. 3 shows a detailed view of an individual page of the record blockof FIG. 2.

FIG. 4 shows a table of block classifications according to a secondexample.

FIG. 5 shows a block directory entry in a block directory block pointingto a corresponding block record in a block records block.

FIG. 6 shows some detail of the page structure of a directory block

FIG. 7A shows the structure of a block directory page of FIG. 6,including a record index and a directory index.

FIG. 7B shows the structure of an obsolete block list page of FIG. 6.

FIG. 8 shows some detail of the page structure of a record block.

FIG. 9 shows the structure of a record page of FIG. 8 in more detail.

FIG. 10 shows a directory block and record block undergoing an update ofblock records and related structures.

DESCRIPTION OF ILLUSTRATED EMBODIMENTS DETAILED FIRST EXAMPLE

Direct data file storage techniques described in the patent applicationsidentified above create lists of blocks from which entries withpredefined values related to the use of the individual blocks areselected. A technique for a content addressable search of these blocklists is used herein. This description refers to accompanying FIGS. 1-3.

FIG. 1 is a table that shows a classification of memory cell blocks onthe basis their contents. Practically all blocks in the memory systemwill be classified as shown. Three separate lists are maintained in thisexample: one of partial blocks, another for obsolete blocks and a thirdfor erased blocks.

The types of blocks recognized in this example are as follows:

-   -   A “program block” has been partially programmed, and contains        valid data of only a single file. Some erased capacity remains        in the block. It may also contain some obsolete data.    -   A “common block” has been partially programmed, and contains        valid data of two or more files. Some erased capacity remains.        It may also contain some obsolete data.    -   A “full common block” has been fully programmed and contains        valid data of two or more files. It may also contain some        obsolete data.    -   A “file block” has been fully programmed, and contains valid        data of a single file. It may also contain some obsolete data.    -   An “invalid block” contains no valid data. The invalid block        contains at least some obsolete data and may contain erased        capacity but does not contain any valid data.    -   An “erased block”, in which the total capacity of the block is        unprogrammed and available to accept data. There are no data in        an erased block. When the memory is full or nearly full of data,        a pool of a specified minimum number of erased blocks is        typically maintained by continuously reclaiming unused capacity        that exists within blocks that are being used.

For purposes of the present example, blocks having the above types areclassified into three classifications as follows:

-   -   A “partial block” contains some unprogrammed capacity, valid        data of one or more files and may contain some obsolete data.        The program block and common block are examples of partial        blocks.    -   An “obsolete block” is a file block or a full common block that        contains some obsolete data. The obsolete block does not contain        any erased capacity, and contains both valid and obsolete data.    -   An “erased block” has the same definition as the block type of        the same name, a block with no data.

It will be noted that these classifications do not cover all blocks inthe memory array, some blocks may remain outside these classificationsand such blocks do not appear in the lists of the present example.

When choosing a block for reclaiming storage capacity, the amount ofvalid data in the blocks (valid data capacity) is a primary factor.Since a reclaim operation on a block requires copying its valid data toanother block, those blocks with the least amount of valid data arechosen first. This is because data copying is time consuming and caninterfere with the efficient operation of the memory system to programand read data. Countering this somewhat is a benefit of blocks thatretain a significant proportion of their capacity erased and availableto store data. Therefore, blocks with more useable erased storagecapacity are not favored for a reclaim operation since the increase instorage space that would result by reclaiming them is less. The partialand obsolete block lists of this specific example are used to classifyblocks on the basis of the amount (number of pages) of valid data theycontain and the amount (number of pages) that remain erased. A purposedescribed herein for these lists is to select one block at a time to besubject to a reclaim operation.

Types and Access of Block Lists

The partial block list (P-list) contains an entry for every partialblock in the system; that is, every block containing both some validdata and some erased capacity. It may also contain some obsolete data.

The obsolete block list (O-list) contains an entry for every block inthe system containing obsolete data, which does not have an entry in thepartial block list.

The erased block list (E-list) contains an entry for every erased blockin the system.

In a specific example of flash memory operation, the following blocklists are maintained:

-   -   P(V)-list A partial block list with entries ordered according to        the valid data capacity stored in the blocks;    -   P(A)-list A partial block list with entries ordered according to        the block address of the blocks;    -   O(V)-list An obsolete block list with entries ordered according        to the valid data capacity stored in the blocks;    -   O(A)-list Obsolete block list with entries ordered according to        the block address of the blocks; and    -   E-list An erased block list.

The P(V)-list, O(V)-list, P(A)-list and O(A)-list act as “directories”to a common set of block records. To select a reclaim block, the entrieswith the lowest valid data capacity values are read from the P(V)-listand O(V)-list. To select an active block, the entry with the highestvalid data capacity value less than or equal to a target value is readfrom the P(V)-list. To select an erased block, the first entry on theE-list is read and removed from the list.

To update an entry in the P-list or O-list, the entry with the targetblock address is read from the P(A)-list or O(A)-list.

Storage Technique for Block Lists

One or more blocks or metablocks are allocated for the storage ofinformation relating to blocks on the block lists identified in theimmediately preceding section. These are known as record blocks, and arewritten or updated in units of one page. Content addressing is used forinformation in record blocks.

Each record block contains a fixed number of logical pages, each ofwhich may be updated by re-writing it to the next available physicalpage. Multiple logical pages are allocated to store records containinginformation for blocks in the lists. These are known as record pages.

A record exists for every block in the block lists. Record pages and therecords within them may be in any order. Records for blocks in differentblock lists need not be kept separate. Obsolete records may exist withinrecord pages, and may be replaced by new records for blocks that havebeen added to the block lists. A record contains the physical address ofa block and a value defining the amount of valid data within the block(valid data capacity), together with other information.

One or more logical pages are allocated to store entries identifyingblocks within one of the individual block lists. These are known as listpages. Separate list pages are used for different block lists. Eachentry in a list page contains a descriptor value, which is the value ofeither the physical address of the block to which it relates or thevalid data capacity within the block (or some other value associatedwith data in the block), together with a pointer to the record for theblock in a record page. Two list entries, each in a different list pagefor a different block list, may point to the same record if the block towhich the record relates appears in two block lists.

Entries in the block lists act as “directory entries” to a common set ofrecords for blocks.

Entries in a list page for the partial block list or obsolete block listare stored in the order of their descriptors. Entries are written inclosely packed format, with unwritten entry locations in the list pagenormally present after the last entry written. List pages storenon-overlapping ranges of descriptors. If a list page becomes full, itsentries may be divided into two list pages by allocating a new logicalpage as a list page. Similarly, if the number of entries in two listpages with adjacent descriptor ranges falls below a threshold, the twolist pages may be combined into one. An index for the record blockcontains the descriptors for the first entry of each list page.

An entry in the partial block list or obsolete block list with a targetvalue for block address or valid data capacity may be found byidentifying the list page with the appropriate descriptor range from therecord block index, reading the page from flash, then performing alinear or binary search within the page for the target entry. The recordfor the target block may then be read from the record page identified bythis entry.

Entries for blocks in the erased block list may be stored in a list pagein which they retain the order in which they were written. Erased blocksare always selected as the oldest entry in the list.

Structure of a Record Block

All entries and indexing information for blocks referenced in the blocklists are contained in one or more record blocks in flash memory. Arecord block is a metablock and is updated in units of a page.

A record block has the following characteristics:

-   -   1. All types of block lists may be stored together in a single        record block.    -   2. Multiple record blocks may be used, if required.    -   3. A record block has a specified number of logical pages, which        is defined as 25% of the number of physical pages in the block        in the present example.    -   4. A record block index section in the most recently written        page provides a mapping for each logical page to a physical        page.    -   5. A logical page may be updated by re-writing it to the next        available physical page.    -   6. A logical page can be allocated to any of the page types used        for block lists or for records for blocks.    -   7. A record block is compacted and re-written in an erased block        when full.

The structure of an example record block is shown in FIG. 2.

Record Block Index

The record block index exists as a section of each page in the recordblock. It is valid only in the most recently written page. The recordblock index contains an entry for each possible logical page, orderedaccording to logical page number. Each entry has 3 fields, as follows:

-   -   1. A numeric code identifying the page type:        -   a. P(V)-list page;        -   b. P(A)-list page;        -   c. O(V)-list page;        -   d. O(A)-list page;        -   e. E-list page;        -   f. Record page; and        -   g. Unallocated logical page.    -   2. Value in the first entry in the page. This allows the range        of values in each of the P(V), P(A), O(V), and O(A) list page        types to be established and cached.    -   3. Pointer to the physical page to which the logical page is        mapped.        Record Page

A record contains all required information relating to a block with anentry one of the lists, and is stored in a record page. A record page issubdivided into three sections, as follows:

-   -   1. Entry status;    -   2. Records; and    -   3. Common block records.

The entry status section comprises a bitmap, indicating whether eachrecord is in use, or is available for allocation to a new block. Therecords section has entries of a fixed size for every block in thelists, with fields defining its attributes as follows:

-   -   1. Block address;    -   2. The capacity of valid data in the block;    -   3. The position of the page write pointer in the block;    -   4. The fileId for the first data group in the block;    -   5. Total number of files for which data exist in the block; and    -   6. Offset to any common block record that exists for the block.        A value of 0 denotes that no common block record exists.

The common block records section has entries with variable sizes, withfields defining other fileIDs in a common block, as follows:

-   -   1. FileIDs for each subsequent data group in a common block; and    -   2. End of records indicator.

The record page may contain obsolete entries resulting from blocks beingremoved from the block lists. Such record may be re-allocated to newblocks that are added to the lists.

The logical page number within a record block and record number withinthat page that are allocated to a block are normally not be changed, asthey are used by list pages to reference the record. However, it ispermissible to move the record for a block to another record numberwithin the same list page, to another list page, or to another recordblock. If the record for a block is moved, the pointers to it in anylist entries must be updated accordingly.

When a record page is modified and re-written, the common block recordsmay be compacted to eliminate any obsolete space and the records updatedto reflect any changes in offset to common block records.

The boundary between records and common block records is dynamic.

The structure of an example block records page is shown in FIG. 3.

List Page

A list page contains a set of entries for blocks, in an order defined bydescriptor values. Valid data capacity is the descriptor in entries inthe P(V)-list and O(V)-list, and block address is the descriptor inentries in the P(A)-list and O(A)-list.

Valid entries occupy a contiguous set of entry locations in a list page,but need not fill the complete page. There are no obsolete entrieswithin the set, and the descriptor values need not be contiguous.

The entries in a list page are in order of the values in theirdescriptor field. The range of the descriptor values does not overlapthe range of descriptor values in any other list page.

When an entry for a block that has been added to a block list needs tobe inserted, the list page with a descriptor range that encompasses thedescriptor value for the new block is identified. A new entry isinserted at the appropriate location in the descriptor range, and thelist page is re-written. When an entry must be removed, the list page iscompacted without the entry and is re-written.

When an addition must be made to a list page that has become full, afree logical page is allocated as a new list page and the descriptorrange of the full list page is divided into two approximately equalnon-overlapping ranges, which are written in the two available listpages.

When the aggregate number of valid entries in two list pages withadjacent descriptor ranges drops below a threshold value (70% of thenumber of entry locations in a list page in this example), the ranges ofthe two list pages are consolidated and written in one of the two listpages. The other unused page then becomes a free logical page.

The fields in an entry in a list page for the P(V)-list and O(V)-listare as follows:

-   -   1. Valid data capacity in the block; and    -   2. Pointer to record for block in a record page. The record page        need not be in the same record block as the list page.

The fields in an entry in a list page for the P(A)-list and O(A)-listare as follows.

-   -   1. Block address; and    -   2. Pointer to record for block in a record page. The record page        need not be in the same record block as the list page.

The field in an entry in a list page for the E-list is as follows:

-   -   1. Block address.        Access Sequence for Records

The following sequence of steps is used to access a record for a targetblock in either the P-list or O-list.

-   -   1. Define P(V)-list, O(V)-list, P(A)-list or O(A)-list as the        target list.    -   2. Read record block index from most recently written page in        the record block. This information may already exist in a cache.    -   3. Determine logical page number allocated to the list page for        the target descriptor value in the target list defined in step        1.    -   4. Read logical page number determined in step 3 from the record        block.    -   5. Search list page read in step 4 to read entry for target        block.    -   6. Read record page from the record block as defined by the        entry read in step 5.    -   7. Read record for target block from the record page read in        step 6.

DETAILED SECOND EXAMPLE

In a second example, as in the first example described above, certainblocks are individually classified according to the data they containand records are maintained for these blocks. Lists are maintained thatare ordered according to a descriptor value related to data stored in ablock. The amount of valid data in a block is an example of such adescriptor value. However, some of the structures and methods used tomanage blocks are different in this second example. The structures andmethods of the first and second examples should be viewed asalternatives, with various combinations of structures and/or techniquesfrom both examples also being considered as part of the presentdisclosure. The second example is described with a focus on differencesfrom the first example. Thus, elements that are common to both examplesmay not be described in detail again with respect to the second example.

Block classifications in the second example are the same as those of thefirst example, with the addition of a “Complete common block”classification. FIG. 4 shows a block classification table that issimilar to that of FIG. 1, except for the additional classification“Complete common block.” Record entries are maintained for each blockhaving a block classification “Partial block”; “Obsolete block”; “Erasedblock” or “Complete common block.” The classification, “Complete commonblock” is used for common blocks that do not contain any erased capacityand that do not contain any obsolete data. Complete common block (CCB)records are maintained with a block record for every complete commonblock. Complete common blocks are not generally subjected to reclaimoperations because they do not contain space that is available forreclaim (neither erased space nor obsolete space). However, when somedata in a complete common block becomes obsolete, the block isreclassified as an obsolete block and may be subject to reclaimoperations. When such reclassification occurs, a block record thatcontains information regarding data stored in the block is needed. Thisinformation is available from the block's preexisting CCB record entry.Thus, by maintaining records on complete common blocks, the transitionfrom complete common block to obsolete block may occur without a heavyburden of searching for information to generate a record for the block.

The classification schemes of FIGS. 1 and 4 are exemplary and otherschemes are also contemplated. In one example (discussed in detaillater), a record may be maintained for all blocks in a memory array atall times. Thus, an additional block classification may be added to thetable of FIG. 4 for file blocks having no obsolete data. In otherexamples, some of the classifications of FIG. 4 may not be needed. Forexample, no records may be maintained for erased blocks or invalidblocks. In yet other examples, blocks may be divided into differentblock types than those of FIG. 4. It will be understood that the blocktypes of FIG. 4 are convenient for particular memory management schemes,but other memory management schemes may use different block types.

A record is maintained for every block in one of the blockclassifications listed in the table of FIG. 4. Records for blocks havingdifferent block classifications may be stored together in the same page.In the present example, dedicated block record blocks are maintainedthat store only block records. In order to facilitate access toindividual record entries in the record blocks, a block directory ismaintained. The block directory and the block records are stored inseparate sets of blocks in flash memory (unlike the first example wherea single block could contain both block directory and block recordspages). FIG. 5 shows a block directory entry 501 in a directory block503 that includes a pointer 505 to the location of a corresponding blockrecord 507 in a block record block 509. Block directory entry 501 alsocontains block address 506.

The block directory contains one block directory entry for each blockfor which an entry exists in the block records. Block directory entriesare stored in non-overlapping ranges of block address values, with eachrange allocated to a separate block directory page. Entries within arange are ordered according to block address value. The block directoryentry for a target block address can be found by reading a single blockdirectory page and performing a binary search within the page. Thus, ablock directory provides a convenient way to locate a particular blockrecord entry according to block address.

In some applications, it is desirable to search for a block by criteriaother than block address. In some cases, descriptor values associatedwith the data stored in blocks may be used for such a search. Forexample, for reclaim purposes, it may be desirable to identify thepartial block with the least amount of valid data. One way to find sucha block would be to search the record entries for all blocks todetermine which block contained the least amount of valid data. However,such searching may add a significant burden. An alternative is tomaintain lists of blocks that are ordered according to the amount ofvalid data they contain (valid data capacity). Thus, where blocks arelisted in order of the amount of valid data they contain, identifyingthe block with the least amount of valid data is simply a matter ofreading the first (or last) entry in the list. Similarly, if a blockwith a particular amount of valid data is required, a binary search mayrapidly identify such a block. The amount of valid data stored in ablock is given by a descriptor value in a list entry. Such a descriptorvalue describes data stored in the block. This is in contrast to blockaddress (used as a descriptor value in the first example), whichdescribes the physical location of the block.

A mechanism incorporating a two-stage search process is provided toaccess a block record according to a descriptor value defined within afield in the record for the amount of valid data in the block. Entriescontaining the valid data capacity values for the classifications ofblocks for which this content addressing mechanism may be used arestored in separate list pages in the block directory. These block listentries are stored in non-overlapping ranges of valid data capacityvalues, with each range allocated to a separate block list page. Entrieswithin a range are ordered according to their valid data capacityvalues. Each block list entry contains a block address, which explicitlyidentifies a block directory entry. Block list entry 511 contains blockaddress 513, which is identical to block address 506 and therebyidentifies block directory entry 501. Block list entry 511 also containsvalid data capacity 515 for the block having block address 513. A blockdirectory entry for a target valid data capacity value can be found byreading a single list page and performing a binary search within thepage to find an entry with the target valid data capacity value, thenreading a single directory page and performing a binary search withinthe directory page to find the entry with the target block address.

A binary search may simply mean looking at an entry in the middle of thepage's descriptor value range. Based on a comparison of the descriptorvalue of this entry with the descriptor value being sought, the searchis limited to half the page. An entry at the midpoint of this half pageis then similarly examined and the search limited to a quarter of thepage. After successive steps, one or more entries are found that havethe descriptor value that is sought. In other examples, moresophisticated binary search algorithms may be used. In some examples, nobinary search is needed because the descriptor value that is sought isthe lowest (or highest) in the list. Thus, the first (or last) entry inthe list is selected.

Block records are directly addressed by entries in the block directory.A page of block records is updated by a read/modify/write operation thatmoves the page to an unprogrammed location in the same or another blockrecords block. Block records in a page must all relate to entries in thesame block directory page. However, one directory page may containentries for more than one block records page. Thus, block records pagemay be updated with consequent need for modification of only a singleblock directory page.

Block Directory

The block directory is an ordered collection of entries identifyingblocks by block address and indicating the locations of correspondingblock records. An entry exists in the block directory for each block forwhich a block record is maintained. In the present example, an entryexists for each partial block, obsolete block, complete common block,and erased block. The block directory is contained in one or moredirectory blocks.

FIG. 6 shows a directory block 621 containing obsolete block and partialblock list pages. FIG. 6 also shows directory pages in the directoryblock. Each directory block contains a fixed number of logical pages,each of which may be updated by re-writing it to the next availablephysical page. A page containing valid entries is allocated a logicalpage number. The number of logical pages in a directory block isspecified as being 25% of the number of physical pages in a block in thepresent example. In other examples, other limits may be specified. Afterthe last page of a directory block has been written, the block iscompacted by writing all valid pages to an erased block and erasing theoriginal directory block.

Block Directory Page

A block directory page contains a set of block directory entries, inorder of their block address values. An example of a block directorypage 731 is shown in FIG. 7A. Valid block directory entries 733 occupy acontiguous set of entry locations in block directory page 731, but neednot fill the complete page so that erased space may remain. Each blockdirectory page contains a record index (described below). Here, blockdirectory page 731 contains record index 735. There are no obsoleteentries within block directory entries 733, and the block address valuesneed not be contiguous. The range of the block address values in a blockdirectory page does not overlap the range of block address values in anyother block directory page.

When an entry for a block needs to be inserted, the block directory pagewith a block address range that encompasses the block address value forthe new block is identified from the information in the directory index.A new entry is inserted at the appropriate location in the block addressrange, and the block directory page is re-written. When an entry must beremoved, the block directory page is compacted without the entry and isre-written.

When an addition must be made to a block directory page that has becomefull, a free logical page is allocated as a new block directory page andthe block address range of the block directory page that has become fullis divided into two approximately equal non-overlapping ranges, whichare written in the two available block directory pages.

When the aggregate number of valid entries in two block directory pageswith adjacent block address ranges drops below a threshold value (70% ofthe number of entry locations in one block directory page in thisexample), the ranges of the two block directory pages are consolidatedand written in one of the two block directory pages. The other unusedpage then becomes a free logical page.

A block directory entry 737 in this example contains two fields: (1) Ablock address; (2) A pointer to a corresponding block record. Thepointer identifies a logical identifier for a block record page and abyte offset of a particular block record within a page. The block recordpage logical identifier identifies one of up to 16 separate block recordpages that may be referenced by entries in the same block directorypage. It is converted to a physical block address and page number by therecord index field within the block directory page containing the entry.The byte offset identifies the location of the block record within theidentified block record page.

A separate valid record index field exists in each valid block directorypage and block list page. It is used to convert logical identifiers forblock record pages to physical block addresses and page numbers at whichthe block record pages are located. Record index 735 contains one entry(such as entry 739) for each logical identifier that is used within anyentry in block directory page 731. A maximum of 16 separate block recordpages may be referenced by block directory entries in a single blockdirectory page. A 4-bit logical identifier is therefore used. In thisway, individual block directory entries may use the 4-bit identifierinstead of a longer physical page location for the corresponding blockrecords page. The record index field serves to translate these logicalidentifiers for all entries in the block directory page.

A valid directory index field 741 exists only in the most recentlywritten block directory or block list page. Information in the directoryindex field in all previously written pages is obsolete. Its purpose isto support the ordering of block directory entries and block listentries and the mapping of logical pages to physical pages. It providesa structure where current data is stored regarding individual pages inthe block directory block. The directory index contains an entry, suchas entry 743, for each possible logical page, ordered according tological page number. Each entry has four fields:

-   (1) Allocation status flag for the logical page-   (2) Type of page, e.g. block directory, PB list, or OB list.-   (3) Block address of first entry in a block directory page or valid    data capacity value of the first entry in a list page (either PB or    OB). This allows the range of block address or valid data values in    each logical page to be established and cached.-   (4) Pointer to the physical page within the block directory to which    the logical page is mapped    Block List Page

A block list page contains a set of block list entries for a singleclassification of block, in order of a descriptor value describing thedata they contain (e.g. the amount of valid data they contain). Anexample of a block list page 751 is shown in FIG. 7B. In the presentexample, a block list page may be a PB list page or OB list page. FIG.7B shows OB list page 751. Valid block list entries 753 may occupy acontiguous set of entry locations in block list page 751, but need notfill the entire page. There are generally no obsolete entries in a blocklist page. Block list entries 753 are ordered by a descriptor value butdescriptor values need not be contiguous and may be repeated. In thepresent example, the valid data capacity values need not be contiguousand may be repeated. The range of descriptor values of a block list pagedoes not overlap the range of descriptor values of any other block listpage for the same block classification.

While valid data capacity is the descriptor value used in the presentexample, other descriptor values may also be used. For example, theamount of erased capacity in a block may be used as a descriptor value.A descriptor value may be derived from a combination of the amount ofvalid data and the amount of erased capacity so that blocks are listedin a desired order for reclaim. In some cases, lists may overlap. Thus,the same block may appear in two different lists. For example, blocksmay be listed both by the amount of valid data that they contain and (ina separate list) by the amount of erased space they contain.

When an entry for a block needs to be inserted, the block list page witha valid data capacity range that encompasses the valid data capacityvalue for the new block is identified from the information in thedirectory index. The block list page is rewritten with the new entryinserted at the appropriate location in the page according to its validdata capacity value. When an entry must be removed, the block list pageis re-written in a new physical location, without the entry.

When an addition must be made to a block list page that has become full,a free logical page is allocated as a new block list page and the validdata range of the block list page that has become full is divided intotwo approximately equal non-overlapping ranges, which are written in thetwo available block list pages.

When the aggregate number of valid entries in two block list pages withadjacent ranges drops below a predetermined threshold amount (forexample, 70% of the number of entry locations in one block list page),the ranges of the two block list pages are consolidated and written inone of the two block list pages. The other unused page then becomes afree logical page.

A block list entry 755 contains two fields: (1) A block address; (2) Adescriptor value, in this example a value indicating the amount of validdata in the block. Unlike the first example, there is no list ordered byblock address (although the directory is ordered by block address). Inthe present example, a list includes a block address from which adirectory entry is found, which in turn indicates the location of acorresponding record. Thus, list entry 753 does not directly indicate arecord in this example. A block list may contain a directory index, butonly the most recently written page contains a valid directory index.The OB list page of FIG. 7B contains an obsolete directory index 757.

Block Records

Block records is a collection of records, each of which containsinformation for a block identified by a block address. One record existsfor each block directory entry. Block records are addressed by blockdirectory entries, and a block directory page must be modified when ablock record page is modified.

Block records are contained in one or more dedicated record blocks suchas record block 861 shown in FIG. 8. Unlike the first example, blocklists and block records are not stored together in the same block. Onlyone block record block may contain un-programmed pages into which blockrecords may be written. All block record information is programmed atthe next un-programmed page location in this block, which is identifiedby a block record write pointer. When the last page in the block hasbeen programmed, the block record write pointer is moved to the firstpage of an erased block. Block record blocks may contain obsolete pagesresulting from block record pages having been rewritten. In someembodiments, valid block record pages do not contain obsolete records asa block records page is rewritten whenever a record in the page becomesobsolete. In other embodiments, obsolete records may remain in validblock record pages. However, the directory entries for obsolete recordsare deleted or replaced with entries pointing to valid records so thatobsolete records are not accessed. Obsolete records in a record page arenot copied when the record page is rewritten.

A block record page contains a set of block records that are referencedby block directory entries within a single block directory page, in thesame order as the entries in the block directory page. FIG. 9 shows anexample of a block record page 965. A block directory page may referencemultiple block record pages. Modification of a block record page may bemade with consequent need for modification of only a single blockdirectory page. Unlike the first example, a block record page accordingto the present example does not include a block record index becauseblock record pages are directly identified by the block directoryentries.

A block record page may be modified by reading the page, then updatingor adding one or more block records. Any obsolete block records areremoved by compacting the page, and the page is programmed at locationidentified by the block record write pointer.

A block record page header stores a reference to the block directorypage with which a block record page is associated, and the length ofblock record information within the block record page. The block recordpage header also stores a record of the number of obsolete pagesexisting in each of the block record blocks at the time the block recordpage was written. This information is only valid in the most recentlywritten block record page header.

An individual block record entry is of variable size. Thus, the recordfor a complete common block may be larger than the record for an erasedblock. Unlike the first example, no separate common block records areais needed. A record block of the present example has fields definingattribute of a block as follows:

-   -   (1) Block address.    -   (2) Type of block, PB, OB, CCB, or EB.    -   (3) The capacity of valid data in the block.    -   (4) The position of the page write pointer in the block.    -   (5) Total number of files for which data exists in block.    -   (6) The fileIDs for each file for which data exists in block.

In other examples, records may contain different fields includingdifferent descriptor values.

Reclaim Process for Block Records in Second Example

Block records are contained in one or more record blocks and aredirectly addressed by block directory entries. Only one record blockcontains erased pages that are available for programming new or updatedblock records. In all other record blocks, all pages have beenprogrammed, but the block may contain fully obsolete or partiallyobsolete pages. Reclaim of the capacity occupied by obsolete blockrecords is performed by designating one record block as the next blockto be reclaimed, and progressively copying pages from this reclaim blockto the page currently designated by the block record write pointer,before erasing the reclaim block.

A reclaim block is selected when a previous reclaim process on a recordblock has been completed and the previous reclaim block has been erased.The record block with the highest number of obsolete pages is selectedas the reclaim block. The number of obsolete pages for each record blockis recorded in the block record page header of the most recently writtenblock record page. The record block containing the block record writepointer may not be selected for reclaim. The selected record blockremains as the reclaim block until the reclaim process has beencompleted and the block has been erased. The erased block is then addedto the erased block pool and may be used again to store data of any kindincluding host data. Thus, a block remains a dedicated record block fora time but is not permanently designated as a record block.

The process of reclaiming block record blocks containing obsolete pagesentails copying a small number of pages containing valid block recordsfrom the block to the page designated by the block record write pointer,in bursts at scheduled intervals. The number of pages in a burst shouldbe the number of pages contained in a metapage for good performance.However, in some cases fewer pages may be written at a time. Programmingthe pages at the block record write pointer may be performed as a singleprogramming operation on a metapage. A burst copy operation of pages inthe reclaim block may be scheduled at intervals defined by progressionof the block record write pointer through the number of page positionscontained in 4 metapages. To program a metapage, the write pointergenerally must point to the first page in a physical metapage when aburst copy operation is scheduled.

In contrast to the reclaim process for block record blocks describedabove, a reclaim process for directory blocks is simply a matter ofcompacting a block directory block when no erased space remains in thedirectory block. Where a block directory block has a maximum of 25%valid pages at any time (logical capacity is 25% of physical capacity inthis example), compaction of such a block results in a block having atleast 75% erased space. When compaction occurs, the block from whichdata is copied becomes an invalid block and is erased to become anerased block. The block is then added to the erased block pool and maybe used to store any kind of data including host data. Thus, a blockremains a dedicated directory block for a time but is not permanentlydesignated as a directory block.

Updating Structures of Second Example

When data is written to a block in the memory array or when a file isdeleted, one or more block records may need to be updated. In addition,the corresponding block directory and list entries may need to beupdated. The following process, as shown in FIG. 10, illustratesupdating various structures of the second example when additional validdata is stored in a partial block (already containing some obsoletedata) causing the block to become an obsolete block.

-   -   (1) Receive address of block that is to store additional data.    -   (2) Look at directory index 171 in last written page of the        block directory block 170 to determine physical page location of        directory page 173 containing the directory entry 175 for this        block.    -   (3) Perform binary search within directory page 173 to find        entry 175 for the block.    -   (4) Determine from logical identifier in entry 175, along with        information in record index 177, the physical page 179 in block        records block 181 that contains the record 183 for this block.        Use offset in directory entry 175 to find the correct record 183        corresponding to the received address.    -   (5) Determine the classification of the block from record 183.        Determine whether storage of additional data causes        classification to change. Here, the block is a partial block and        the additional data fills the remaining space in the block so        that it becomes an obsolete block.    -   (6) Copy the contents of record page 183 to the location        indicated by write pointer 185, with record 183 for the present        block updated to reflect different type of block, valid data,        position of page write pointer etc.    -   (7) Copy directory page 173 to the next available physical page        in block directory block 170. Write new directory page with        updated entry and record index to reflect new physical location        of record page. Also, update directory index in the new physical        page.    -   (8) Look at directory index again to determine the physical page        location of a partial block list page 187 containing an entry        189 for the block. (In some other cases may look at more than        one list).    -   (9) Perform binary search in page 187 to find list entry 189        with a descriptor value equal to that of the present block. If        more than one list entry has the descriptor value, then search        all matching entries by block address.    -   (10) Copy partial block list page 187 to new location with entry        189 for the present block deleted. New partial block page        includes updated directory index with new physical location for        partial block page.    -   (11) Look at directory index again to determine the physical        page location of an obsolete block list page that covers the        valid data per block range which includes the amount of valid        data in the present block (not shown).    -   (12) Copy the obsolete block list page, adding a new entry for        the present block at the appropriate offset, according to the        amount of valid data now in the block. The new obsolete block        list page includes updated directory index indicating new        location for obsolete block list (not shown).

The above steps are not necessarily carried out in the order shown. Somesteps may be carried out in parallel. For example, writing of an updatedobsolete block list page and an updated partial block list page may bein parallel as part of a metablock write.

DETAILED THIRD EXAMPLE

In a third example, a record is maintained for each block in the memoryarray at all times. This may involve one or more additionalclassifications of blocks, for example, an additional classification forfile blocks that do not contain obsolete data may be added to theclassifications of the second example shown in FIG. 4. Althoughmaintaining a record for each block adds to the total number of recordsthat are maintained, it may allow simpler structures to be used. Thethird example may operate similarly to the second example apart fromhaving a record for each block.

For example, where records are maintained for every block, directoryentries are also maintained for every block. Directory entries have afixed, uniform size. So, a directory page may contain a fixed number ofentries that are sequentially ordered by block address. Thus, eachdirectory page covers a fixed block address range. Because entrieswithin such a page are at predetermined offsets according to their blockaddress, it is unnecessary to separately record a block address in eachentry. Finding a directory entry for a particular block may be a matterof finding the directory page that covers the block address range thatincludes the block, and then going to the entry within that page at anoffset given by the difference between the block address of the firstentry of the directory page and the desired block address. Thus, nobinary search of a directory page may be needed. In contrast, recordsare generally variable in size, so a record page does not alwaysmaintain a fixed number of entries. Unlike previous examples, in thepresent example records may be maintained for blocks for which no entryexists in any list.

Maintaining a record for each block in the memory is convenient for someapplications. For example, descriptors may be maintained regardingphysical characteristics of a block. One example of such a descriptor isan erase count. An erase count indicates the number of times aparticular block has been erased and may be used for wear levelingpurposes. One or more lists may order blocks according to their erasecount. Alternatively, a record may include a time stamp from the lasttime a block was erased so that blocks may be ordered in a list by timesince their last erase.

Although the various aspects of the present invention have beendescribed with respect to exemplary embodiments thereof, it will beunderstood that the present invention is entitled to protection withinthe full scope of the appended claims.

1. A memory system comprising: a nonvolatile memory array including afirst plurality of individually erasable blocks that each contain data;and a list that contains an entry for each of the first plurality ofblocks, the entries in the list ordered according to the amount of validdata stored in each of the first plurality of blocks.
 2. The memorysystem of claim 1 further comprising a plurality of records, each of theplurality of records corresponding to one of the first plurality ofindividually erasable blocks, each of the plurality of recordscontaining information regarding its corresponding block.
 3. The memorysystem of claim 2 wherein the list entries are maintained in a pluralityof list pages in a first block and the plurality of records aremaintained in a record page in a second block.
 4. The memory system ofclaim lwherein the plurality of blocks consists of all blocks of thenonvolatile memory array that contain both erased space and valid data.5. The memory system of claim lwherein the plurality of blocks consistsof all of the blocks of the nonvolatile memory array that containobsolete data and do not contain erased space.
 6. A nonvolatile memoryarray, comprising: a plurality of individually erasable blocks; aplurality of records for the plurality of blocks, each of the pluralityof records containing information regarding one of the plurality ofblocks; a directory that contains a plurality of directory entries, eachof the plurality of directory entries including the location of one ofthe plurality of records; and a list that contains a plurality of listentries, each of the plurality of list entries including a descriptorvalue that describes data stored in an individual one of the pluralityof blocks, the plurality of list entries ordered by respective theirdescriptor values.
 7. The nonvolatile memory array of claim 6 whereinthe plurality of records is located in a first block and the directoryand the list are maintained in a second block.
 8. The nonvolatile memoryarray of claim 6 wherein the descriptor values represent the amount ofvalid data stored in respective ones of the plurality of blocks.
 9. Thenonvolatile memory array of claim 6 wherein the plurality of blocksconsists of all of the blocks in the nonvolatile memory array thatindividually contain both erased space and valid data.
 10. Thenonvolatile memory array of claim 6 wherein the plurality of blocksconsists of all of the blocks of the nonvolatile memory array thatindividually contain both obsolete data and do not contain erased space.11. The nonvolatile memory array of claim 6 wherein the plurality ofblocks consists of all blocks of the nonvolatile memory array.
 12. Thenonvolatile memory array of claim 6 wherein the list is maintained in aplurality of pages that each stores a distinct range of list entries.13. A non-volatile memory system with storage cells grouped into blocksof memory cells that are erased prior to reprogramming data in pages ofthe blocks, comprising: a first plurality of blocks storing data; afirst plurality of pages containing a plurality of records thatindividually include at least a descriptor value that is descriptive ofdata stored in the corresponding one of the first plurality of blocks,and a second plurality of pages containing pointers to the locations ofrecords in the first plurality of pages, wherein valid records in anindividual one of the first plurality of pages are limited to recordsindicated by pointers stored in one of the second plurality of pages.14. The nonvolatile memory system of claim 13, wherein said firstplurality of pages is located in a first group of one or more blocks,and said second plurality of pages is located in a second group of oneor more blocks.
 15. The nonvolatile memory system of claim 13, whereinsaid first plurality of pages is located in a first block that is notone of the first plurality of blocks and said second plurality of pagesis located in a second block that is not one of the first plurality ofblocks.
 16. The nonvolatile memory system of claim 13 further comprisinga list located in a third plurality of pages, the list containing aplurality of entries individually corresponding to ones the firstplurality of blocks, an entry containing a descriptor value for itscorresponding block.